PATENT 

Attorney Docket No. PI 895US 



IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 



In re Application of: 



Arditi et al. 



Art Unit: Unassigned 



Application No. Unassigned 



Examiner: Unassigned 



Filed: 



September 11,2003 



For: 



ELECTRONIC SIGNATURE METHOD, 
PROGRAM AND SERVER FOR 
IMPLEMENTING THE METHOD 



CLAIM OF PRIORITY 



Commissioner for Patents 
P.O. Box 1450 

Alexandria, Virginia 223 13-1450 
Dear Sir: 

In accordance with the provisions of 35 USC 119, Applicants claim the priority of the 
application or the applications (if more than one application is set out below): 

Application No. 02 1 1548, filed in France on 18 September 2002. 

A certified copy of the above-listed priority document is enclosed. 



Respectfully submitted, 




Brian C. Rupp, Re^^5. 35,665 
One of the Attorneys for Applicant(s) 



GARDNER CARTON & DOUGLAS LLP 
191 N. Wacker Drive, Suite 3700 
Chicago, Illinois 60610-1698 
(312) 569-1000 telephone 
(312) 569-3000 facsimile 



Date: September 11, 2003 



CH02/22263922.1 



IN 5 ! 



I INSTITUT 
NATIONAL DE 
LA PROPRIETE 
INDUSTRIELLE 



BREVET D' INVENTION 



CERTIFICAT D'UTILITE - CERTIFICAT D'ADDITION 



COPIE OFFICIELLE 

Le Directeur general de I'lnstitut national de la propriete 
industrielle certifie que le document ci-annexe est la copie 
certifiee conforme d'une demande de titre de propriete 
industrielle deposee a I'lnstitut. 

Fait a Paris, le LLAML2013 



Pour le Directeur general de I'lnstitut 
national de la propriete industrielle 
Le Chef du Departement des brevets 




Martine PLANCHE 




ETA8LISSEMENT PUBLIC NATIONAL CREE PAR LA LOI N» 51-444 DU 19 AVRIL 1951 



1er depot 



IN 5 ! 



NATIONAL OK 
L* FttOf Btlfi 
INbUSTBICLLK 

26 bis, rue de Saint Petersbourg 
75800 Paris Cede* 08 

Telephone : 01 53 04 53 04 Telecopie : 01 42 94 86 54 p^^^l 



f R6serv6 a riNPl h 



BREVET ©'INVENTION 

CERTIFICAT D'UTILITE 

Code de Ja propriete inteilectuelle - Livre VI 

REQUt?TE EN D&JVRANCE 1/2 

Remplir imperativement la 2eme page. 

Cet imprime est a rempiir lisiblement a Tencre noire 



N° 11354*01 



STWSept 2002 
7© inpi paris 

0211548 



DATE 
UEU 



N* D'ENREGISTREMENT 
NATIONAL ATTRtBUfc PAR UNPI 

DATE DE 0£>OT ATTRIBUTE 
PAR L'INPi 



1 8 SEP. 2002 



Vos references pour ce dossier 

(faculiatif) BLO/MGO-BFF020292 



DB 540 W/l 90500 



D NOM ET ADRESSE DU DEMANDEUR OU DU MANDATAIRE 

A QUI LA CO RRES PON DANCE DOIT ETRE ADRESSEE 
* • 

CABINET PLASSERAUD 

84 RUE D'AMSTERDAM 

75009 PARIS 



Confirmation cPun depot par telecopie Q N° attribue par HNPi a la telecopie 



□ NATURE DE LA DEMANDE 


Cochez Tune des 4 cases suivantes 


Demande de brevet 




Demande de certificat d'utilite 


□ 


Demande divisionnaire 

Demande de brevet initiale 
ou demande de cerlifical d'utilite' initiale 


□ 

N° Date 1 / / | 
N° Date L .1... ./„_„ J 


Transformation d'une demande de 
brevet europeen Demande de brevet initiale 


□ 

N° Date 1 II J 



H| TITRE DE L'INVENTtON (200 caracteres ou espaces maximum) 

PROCEDE DE SIGNATURE ELECTRONIQUE, PROGRAMME ET SERVEUR POUR LA MISE EN OEUVRE DU 
PROCEDE, 



□ DECLARATION DE PRIORITE 
OU REQUETE DU BENEFICE DE 
LA DATE DE DEPOT D'UNE 
DEMANDE ANTERIEURE FRANQA1SE 


Pays ou organisation 

Date ! . 7 L. ... J N° 

Pays ou organisation 

Date L . ./ / ! N° 

Pays ou organisation 

Date [ / /„ ) N° 

1 1 S'il y a d'autres priorites, cochez la case et utillsez IMmprime «Suite» 


0 DEMANDEUR 


1 1 S'il y a d'autres demandeurs, cochez la case et utiUsez I'imprimS «Sufte» 


Norn ou denomination sociale 


FRANCE TELECOM 


Prenoms 




Forme juridique 


Societe Anonyme 


N° SIREN 


; 3 8 0 - 1 2 9 -8 6 -6 | 


Code APE-NAF 


j . . . j 


Adresse 


Rue 


6, pface d'AHeray 


Code postal et ville 


75015 PARIS 


Pays 


FRANCE 


Nationality 


Francaise 


N° de telephone (Jaadtaiif) 




N° de telecopie (facultatif) 




Adresse electronique (facultatif) 





1er depot 




■ IMftTITUT 
NATIONAL DC 

La pRorRitrt 



BREVET DINVENTION 
CERTIFICAT D'UTILITE 



REQUITE EN D£UVRANCE 2/2 



REMISE DES fJEC 
DATE 



LIEU 



W&EPT 2002 
75 INPI PARIS 

02 1 1548 



N° O'ENREGISTREMENT 



Vos references pour ce dossier : 

(facultatif) 


BLO/MGO-BFF020292 


O MANDATAIRE 




Nom 




Prenom 




Cabinet ou Soctete 


Cabinet PLASSERAUD 


N °de pouvoir permanent et/ou 
de lien contractuel 




Adresse 


Rue 




Code postal et ville 


75009 | PARIS 


N° de telephone (facultatif) 




N° de telecopie (facultatif) 




Adresse electronique (facultatif) 




Q INVENTEUR (S) 




Les inventeurs sont les demandeurs 


| jOui 

fx] Non Dans ce cas fournir une designation d'inventeur(s) separee 


U RAPPORT DE RECHERCHE 


Uniquement pour une demande de brevet (y compris division et transformation) 


£tablissement immediat 
| ou etablissement differe 


B 
□ 


Paiernent echelonne de la redevance 


Paiernent en deux versements, uniquement pour les personnes physiques 

□Oui 
□ Non 


O REDUCTION DU TAUX 
DES REDEVANCES 


Uniquement pour les personnes physiques 

CZlRequise pour la premiere fois pour cette invention (joindre tm avis de non-imposition) 
CIlRequise anterieurement a ce depot (joindre une copie de la decision d'admission 
pour cette invention ou indiquersa reference) : \ 




Si vous avez utilise rimprime «Suite», 
indiquez !e nombre de pages jointes 






03 SIGNATURE DU DEMANDEUR 
OU DU MANDATAIRE f 
{Nom et qualite du signatairejv~-_— J. 

Bertrand LOISEL >^ 
CPln° 94-31 1 




VISA DE LA PREFECTURE 
OU DE L'INPI 

0^ 



La loi n°78-17 du 6 janvier 1978 relative a Tinformatique, aux fichiers et aux liberies s'applique aux reponses faites a ce formulaire. 
Elle garantit un droit d'acces et de rectification pour les donnees vous concernant aupres de I'lNPL 



1er depot 



PROCEDE DE SIGNATURE ELECTRON1QUE, 
PROGRAMME ET SERVEUR POUR LA MISE EN CEUVRE DU PROCEDE 

La presente invention conceme les techniques de cryptographie 
utilisant des cles publiques. Elle se rapporte plus particulierement aux 
methodes de certification de cles cryptographiques. 

L'objet fondamental permettant d'avoir confiance en la partie pubiique 
d'une cle cryptographique (cle pubiique) est ie certificat. Le standard de 
certificat utilise dans de nombreux reseaux dont Hntemet est X.509, version 3. 
Une specification en est fournie par le groupe de travail PKIX de I'lETF 
("Internet Engineering Task Force") dans la Request For Comments (RFC) 
3280, "Internet X.509 Public Key Infrastructure; Certificate and Certificate 
Revocation List (CRL) Profile" publiee en avril 2002. Le certificat est un objet 
comprenant notamment: 

• la cle pubiique a certifier; 

• I'identite de son possesseur; 

• une periode de validite; 

• une signature cryptographique de ces donnees par la cle privee d'une 
Autorite de Certification (AC en abrege) emettrice du certificat. 

Avoir confiance en la cle pubiique associee a une identite revient a 
s'assurer de la validite du certificat. Pour PKIX, un certificat est valide a un 
instant T donne (en termes de confiance): 

• soit s'il est explicitement declare comme "certificat de confiance". En 
pratique, les certificats des utilisateurs ne sont jamais declares de 
confiance. On declare plutot un nombre reduit de certificats de confiance, 
consistant en les certificats de certaines AC; 

• soit s'ii verifie les conditions suivantes: 

- la signature cryptographique du certificat est mathematiquement 
valide; 

- I'instant T fait partie de la periode de validite du certificat; 

- le certificat n'est pas revoque a I'instant T; 
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- la cle publique de I'AC emettrice est disponible par un certificat de 
I'AC, et ce certificat de I'AC est lui-meme valide a Tinstant T. 

Un certificat est revoque a un instant TR de sa periode de validite si, a 
partir de cet instant, TAG qui I'a emis a un doute sur la compromission de la cle 
privee associee au certificat. Le but est d'invalider le certificat a partir de TR. 
En pratique, c'est le cas quand I'utilisateur du certificat perd sa cle privee 
associee a la cle publique certifiee ou se la fait voler, quand I'AC ne souhaite 
plus certifier la cle de I'utilisateur (par exemple quand un employe quitte une 
entreprise), etc. 

D'apres PKIX, un certificat revoque doit etre mis dans une liste de 
revocation (CRL, "Certificate Revocation List") qui est une liste de certificats 
emis par une AC et revoques par celle-ci. En theorie, une AC ne doit jamais 
retirer un certificat d'une CRL. Par exemple, si une signature est emise a un 
instant T avec un certificat revoque a T, il faut pouvoir controler de fagon 
perenne que le certificat etait bien revoque a T et done la signature invalide. 

II existe deux moyens courants de controler la non-revocation d'un 
certificat donne: 

• I'acces a la CRL. Le verificateur du certificat telecharge la CRL aupres 
d'un serveur, verifie la signature de la CRL puis recherche le certificat a 
verifier dans la CRL; 

• le controle de non-revocation en ligne. Afin d'eviter au verificateur de 
telecharger des CRL potentiellement volumineuses, un protocoie en ligne 
a ete defini pour effectuer le controle sur seulement un ou quelques 
certificats. II s'agit du protocoie OCSP decrit dans la RFC 2560, "Internet 
X.509 Public Key Infrastructure; Online Certificate Status Protocol - 
OCSP, publiee en juin 1999 par I'lETF. Selon ce protocoie, le verificateur 
du certificat adresse une requete OCSP a un serveur OCSP dependant 
de TAG emettrice, recupere la reponse OCSP signee en provenance de 
ce serveur, verifie la signature de la reponse OCSP et analyse cette 
reponse. 

L'utilisation d'OCSP est en ligne. L'utilisation des CRL est soit en ligne, 
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soit hors ligne mais avec mise a jour reguliere des CRL. 

Dans une infrastructure a cle publique, lorsqu'un certificat arrive a 
expiration, un mecanisme de renouvellement permet a I'Autorite de 
Certification de delivrer un nouveau certificat a I'utilisateur sans avoir a 
effectuer de nouveau la phase d'enregistrement, qui consiste en la collecte et 
la verification des donnees relatives a I'utilisateur. 

Les certificats au format X.509 sont produits a des fins exprimees 
explicitement, appelees "key usage" ("usage de cle", par exemple: signature 
electronique, chiffrement, authentication, horodatage, serveur SSL, etc). Un 
certificat peut avoir un key usage composite. Cependant, afin de limiter les 
dangers en cas de compromission d f un certificat, il est prudent et courant de 
n'attribuer qu'un nombre restreint de ces key usages a un meme certificat. 
Ainsi, un utilisateur pourra dans certains cas disposer de plusieurs certificats, 
chacun correspondant a une utilisation differente. Le probleme est alors d'une 
part la difficulty pour Tutilisateur de s'y retrouver parmi ces certificats, et d'autre 
part un cout de gestion eleve pour I'autorite de certification. II est done 
interessant de pouvoir diffuser des certificats avec un key usage restreint, le 
moins possible par utilisateur, sans pour autant restreindre I'utilisation 
applicative que cet utilisateur pourra en faire. 

Les mecanismes cryptographiques a cle publique sont utilisables pour 
rendre plusieurs services ayant des caracteristiques differentes, qui justifient un 
traitement different des certificats servant a rendre chacun des services. Parmi 
ces services, on peut citer: 

• la confidentiality (chiffrement): les donnees chiffrees doivent pouvoir etre 
recouvrees en cas de perte de la cle privee, sous peine d'etre perdues 
definitivement. Pour cette raison, les cles de chiffrement sont 
sequestrees et recouvrables; 

• la signature electronique: la cle de signature doit exister en un seul 
exemplaire, possede par le titulaire du certificat, afin d'etre certain que 
personne d'autre n'a pu realiser de signature en son nom. La cle ne 
pouvant etre dupliquee, on ne peut pas la sequestrer et elle doit etre 
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distincte de la cle de chiffrement. Les signatures doivent etre verifiables 
au-dela de la duree de validite du certificat, de sorte qu'il faut conserver 
le certificat pour pouvoir effectuer ces verifications; 

♦ I'authentification: la cle d'authentification doit egalement etre unique, 
done distincte de celle de chiffrement. Mais il faut eviter que Ton puisse 
faire effectuer a I'utilisateur une signature electronique en lui faisant 
croire qu'il ne fait que s'authentifier. Cela pourrait etre fait en remplagant 
par un message le defi utilise dans un schema d'authentification par defi- 
reponse a cle publique. Un tel message risquerait d'etre signe par 
Putilisateur a son insu. II faut done aussi distinguer la cle 
d'authentification de la cle de signature. De plus, !e certificat 
d'authentification n'a en general pas besoin d'etre conserve au-dela de 
sa duree de vie, puisqu'il n'est utilise que dans des operations a 
verification unique, instantanee, et non persistantes. 

II est done souvent necessaire de specialiser les certificats, et un 
utilisateur qui veut utiliser plusieurs des services ci-dessus a besoin de 
disposer d'autant de certificats. Les certificats cryptographiques ont une duree 
de vie determinee dans la Politique de Certification de I'Autorite de Certification 
qui les emet. Cette duree est typiquement d'un a trois ans pour des certificats 
d'utilisateurs. 

Cette duree etant longue, il est necessaire de prevoir la possibility de 
compromission de la cle certifiee au cours de la periode de validite du certificat. 
Un mecanisme de revocation et de controle de revocation est done mis en 
place pour permettre d'invalider un certificat qui ne doit plus etre utilise. D'autre 
part, le fait qu'une signature electronique ait ete effectuee avec un certificat de 
duree de vie relativement longue ne donne que peu dedications sur la date a 
laquelle la signature a ete effectuee. II faut done coupler le mecanisme de 
signature electronique a un mecanisme d'horodatage. 

La fonction de signature electronique permet de garantir ('authenticity 
d'un document, e'est-a-dire d'authentifier de fagon sure son ou ses signataires 
et de garantir que le document n'a pas ete modifie (integrite). La signature 
electronique est souvent utilisee pour garantir la non-repudiation. La non- 
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repudiation d'un document consiste a se premunir contre un deni ulterieur de 
son auteur. 



Les formats les plus couramment utilises pour des messages signes 



sont: 



5 • PKCS#7, publie par la societe RSA Security, Inc. et par IMETF en mars 

1998 (RFC 2315, "PKCS #7: Cryptographic Message Syntax; Version 
1.5"), qui a ete repris dans CMS ("Cryptographic Message Syntax", 
RFC 2630, IETF, juin 1999). Ces standards sont utilises notamment 
dans la specification S/MIME ("Secure Multipurpose Internet Mail 

10 Extensions") pour les courriers electroniques signes. lis reposent sur des 

certificats issus de PKIX (X.509;CRL, OCSP) et sont "extensibles" dans 
le sens ou il est possible de rajouter des extensions (complements 
d'information) signees (authenticatedAttributes) ou non 
(unauthenticatedAttributes); 

15 . • XML-DSig, faisant partie de la famille des formats de donnees XML 

("extended Markup Language"). Ce format permet d'utiliser les certificats 

issus de PKIX, et est egalement extensible; 
• PGP correspondant aux messages signes issus du logiciel PGP ("Pretty 

Good Privacy" commercialise par la societe Networks Associates 
20 Technology, Inc.) et de ses analogues. Ses certificats sont differents de 

ceux issus de PKIX. 

Ces formats de signature electronique imposent naturellement que le 
certificat de signature ait un key usage permettant la signature. Cependant, le 
key usage en question n'est pas toujours le meme en fonction des outils 
25 utilises. Par exemple, les logiciels de messagerie "Netscape Mail" de la societe 
Netscape Communications Corporation et "Outlook Express" de la societe 
Microsoft Corporation requierent des key usages differents. En outre, il est 
interdit de signer si le certificat n'a pas un de ces key usages. 

II existe des services permettant a un utilisateur de realiser une 
30 signature electronique sans disposer lui-meme d'un materiel cryptographique. 
Des services de ce genre peuvent fonctionner sous plusieurs modes: 
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1/ I'utilisateur est enregistre aupres d'un serveur qui conserve sous forme 
chiffree une cle de signature bloquee et un certificat a son nom. 
Lorsque I'utilisateur souhaite effectuer une signature, il envoie au 
serveur les donnees a signer, ainsi qu'un mot de passe pour le 
dechiffrement et le debiocage de sa cle de signature. Le serveur utilise 
ce mot de passe et ces donnees pour effectuer la signature, et renvoie 
le resultat a I'utilisateur. Un inconvenient de ce mode de 
fonctionnement est que I'utilisateur n'a pas la maitrise de ses moyens 
de signature. Puisque les signatures ne se font pas sur son poste, il ne 
peut etre certain que le serveur ne va pas effectuer d'autres signatures 
a son insu. 

21 I'utilisateur est enregistre aupres d'un serveur qui conserve sous forme 
chiffree une cle de signature et un certificat a son nom. Lorsque 
I'utilisateur souhaite effectuer une signature, il s'authentifie aupres du 
serveur, et le serveur lui envoie sa cle de signature chiffree. 
L'utilisateur dechiffre sa cle grace a un mot de passe connu de lui seul, 
effectue sa signature grace a cette cle, puis efface cette cle de son 
poste de travail. Un inconvenient de ce mode de fonctionnement est la 
presence des cles de signature dans une base de donnees du serveur. 
Un individu malveillant qui aurait acces a la base de cles pourrait tenter 
une attaque sur ces cles chiffrees afin de les dechiffrer, et par la suite 
de s'en servir pour effectuer des signatures a I'insu du titulaire de la 
cle. 

Quand on utilise une signature electronique pour assurer la non- 
repudiation, on souhaite que la signature soit valide un certain temps. En 
general, la validite necessaire pour la signature (couramment de I'ordre de la 
dizaine d'annees) est largement superieure a la periode de validite d'un 
certificat (couramment un an). En outre, on souhaite generalement ne pas 
disposer seulement d'une signature, mais egalement de la date (voire de 
I'heure) de signature. 

II existe plusieurs methodes bien connues pour placer une signature 
dans le temps (horodatage) et pour etendre la periode de validite d'une 
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signature au-dela de celle du certificat du signataire: 

• horodatage non consensuel: le signataire place lui-meme la donnee 
d'horodatage dans son document et signe cette donnee comme partie 
integrante du document. Cela ne garantit que Taccord du signataire lui- 
meme sur I'heure, et ne permet pas de railonger la validite de la 
signature. Dans une autre realisation, I'horodatage non consensuel est 
appose par un serveur et conserve avec la signature; 

• horodatage consensuel: le signataire et le destinataire du document 
signe se mettent d'accord sur un horodatage, que le signataire place 
dans son document et qu'il signe en meme temps. Une variante consiste 
a faire d'abord signer I'horodatage par le destinataire, et a piacer plutot 
cet horodatage signe dans le document. Dans les deux cas, selon le 
degre de protection offert par le protocole, on peut considerer que la 
signature est correctement placee dans le temps. Par contre, cela ne 
permet pas non plus de railonger la validite de la signature; 

• horodatage sur: une fois le document signe, le signataire fait appel a un 
"tiers d'horodatage". C'est un tiers de confiance disposant d'une cle et 
d'un certificat de longue duree, c'est-a-dire dont la duree couvre la 
periode de validite de la signature. Le tiers d'horodatage lui renvoie un 
jeton d'horodatage qui comprend I'horodatage et une reference unique 
au document signe, le jeton etant lui-meme signe par le tiers 
d'horodatage avec sa cle de longue duree. Ce jeton garantit ('instant 
d'horodatage du document de fa?on cryptographiquement sure. Cela 
permet d'une part de definir I'heure de signature par I'heure du jeton, et 
d'autre part de railonger la validite de la signature en Tetendant a la 
periode de validite du jeton d'horodatage. II existe notamment un 
standard IETF sur I'horodatage, a savoir le protocole TSP (RFC 3161, 
"Internet X.509 Public Key Infrastructure; Time-Stamp Protocol", aout 
2001). 

Plusieurs procedes sont utilisables pour Tauthentification d'un 
utilisateur aupres d'un serveur: 
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le mot de passe statique. II s'agit d'une chaine de caracteres que 
Putilisateur transmet au serveur. Le serveur peut connaTtre egalement ce 
mot de passe et le comparer directement la valeur transmise a la valeur 
connue. Sinon, il peut connaTtre le resultat d'une operation effectuee sur 
ce mot de passe, et il effectue d'abord cette operation sur la valeur 
transmise avant d'effectuer la comparaison; 

le questionnaire. Plusieurs questions sont posees a I'utilisateur, qui est 
cense etre le seul a connaitre les reponses, et qui a prealablement 
repondu aux memes questions pour en enregistrer les reponses. Les 
questions sont en general du type: nom de jeune fille de la mere, equipe 
de football preferee, heros de dessin anime favori, nom du chien, etc.; . , 

le mot de passe calcule. L'utilisateur possede un dispositif qui effectue un 
calcul, a chaque fois different, prenant en compte une cle secrete 
partagee entre le dispositif et le serveur, et un element pseudo-aleatoire 
tel que Pheure. Le serveur effectue le meme calcul et compare les 
resultats. Si les valeurs sont identiques, Putilisateur est bien en 
possession du dispositif, done il est bien celui qu'il pretend etre; 

le mot de passe non reutilisable. L'utilisateur possede un certain nombre 
de codes a usage unique, par exemple sous la forme de cartes a gratter, 
qui sont references aupres du serveur. Si le code presente pour 
s'authentifier fait bien partie de ceux que Putilisateur est cense posseder, 
alors Pauthentification reussit; 

le defi-reponse a cle secrete. L'utilisateur partage une cle secrete avec le 
serveur. Le serveur envoie un nombre aleatoire a Putilisateur ( M defi"). 
L'utilisateur effectue un calcul sur ce defi a Paide de la cle secrete et 
renvoie le resultat du calcul ("reponse"). Le serveur effectue le meme 
calcul et compare son resultat avec la reponse renvoyee par Putilisateur. 
En cas de concordance, Putilisateur est authentifie; 

le defi-reponse a cle publique. L'utilisateur est seul a disposer d'une cle 
privee. Le serveur connaTt la cle publique correspondant a cette cle 
privee, par exemple sous la forme d'un ^certificat. Le serveur envoie un 
defi aleatoire a Putilisateur, qui effectue sur ce defi un calcul a Paide de sa 
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clef privee. La reponse resultante est retournee au serveur qui lui 
applique ie calcul inverse a I'aide de la cle publique. S'il retrouve le defi 
qu'il avait envoye, I'utilisateur est authentifie. 

II est a noter qu'il ne suffit generalement pas de disposer d'une 
ressource d'authentification pour signer electroniquement un document. Pour 
effectuer une signature electronique, il faut etre le seul a disposer d'un secret, 
alors que dans la plupart des mecanismes d'authentification (sauf le defi- 
reponse a cle publique), le secret doit etre partage afm de pouvoir etre verifie 
par le serveur. 

Un but de la presente invention est de proposer un procede simple et 
efficace permettant a un utilisateur disposant de ressources d'authentification 
d'effectuer une signature electronique. 

L'invention propose ainsi un procede de signature electronique depuis 
un poste client, comprenant les etapes suivantes: 

IN authentifier le poste client aupres d'un serveur, en etablissant ainsi un 

canal de communication authentifie entre le poste client et ledit serveur; 
/B/ generer un couple cle privee - cle publique au poste client; 
ICI transmettre du poste client au serveur, sur le canal authentifie, une 
requete de certificat de signature generee au moyen d f au moins la cle 
publique; 

IDI transmettre du serveur au poste client, sur le canal authentifie, un 
certificat de signature obtenu en reponse a ladite requete; 

IEI calculer une signature cryptographique au poste client au moyen de la 
cle privee, puis detruire la cle privee au poste client; et 

/F/ mettre en forme la signature calculee a Taide du certificat de signature 
regu par le poste client sur le canal authentifie. 

De fa<?on usuelle, I'authentification du poste client s'entend, selon le 
contexte d'utilisation du procede, comme une authentication de la plate-forme 
materielle et/ou logicielle du poste ou comme une authentication d'un abonne 
ou d'un utilisateur du poste. 
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Une phase prealable consistera generalernent en un enregistrement du 
poste client (ou de son utilisateur) aupres d'une AC avec laquelle coopere le 
serveur, ou d'une Autorite d'Enregistrement associee a cette AC. Cette phase 
prealable permet d'obtenir les donnees necessaires a la creation d'un certificat 
de signature pour le poste. 

Le certificat de signature obtenu par le serveur a de preference une 
duree de validite relativement courte, typiquement d'une journee au plus. 

Le procede permet a un utilisateur disposant simplement de 
ressources d'authentification d'effectuer une signature electronique, tout en ne 
requerant qu'une gestton simple des cles et des certificats. Meme si un 
horodatage (consensuel ou non, sur ou non) peut etre adjoint a la signature 
ainsi realisee, la duree de validite du certificat permet deja de placer la 
signature dans le temps. 

Dans une realisation preferee, les etapes ICI et IEI sont executees en 
parallele au poste client. II n'est en effet pas necessaire que le client attende de 
disposer du certificat pour proceder a la signature cryptographique, et ensuite il 
n'a plus besoin de la cle privee. 

Le procede est bien adapte aux environnements permettant le 
chargement duplications entre le serveur et les clients, au moyen de 
langages a code mobile, dont le plus repandu est le langage "Java" defini par 
la societe Sun Microsystems, Inc. Dans ce cas, une possibility avantageuse est 
que les etapes /B/, ICI, IE/ et IF/ soient au moins en partie executees au poste 
client sous le controle d'un programme telecharge par le serveur en reponse a 
I'etape IN. 

Dans ce contexte, ('invention a aussi pour objet un serveur d f assistance 
a la signature electronique, comprenant des moyens d'authentification d'un 
poste client pour etablir un canal de communication authentifie avec ceiui-ci, 
des moyens pour obtenir un certificat de signature en reponse a une requete 
regue du poste client sur le canal authentifie et pour transmettre ledit certificat 
au poste client sur le canal authentifie, et des moyens pour telecharger vers le 
poste client un programme ecrit en langage a code mobile et incluant des 
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instructions pour controler au moins en partie I'execution des operations 
suivantes par le poste client: 

- generation d'un couple cle privee - cle publique au poste client apres 
etablissement du canal authentifie; 

- transmission au serveur, sur le canal authentifie, d'une requete de 
certificat de signature generee au moyen d'au moins la cle publique; 

- reception, sur le canal authentifie, du certificat de signature transmis par 
le serveur en reponse a ladite requete; 

- calcul d'une signature cryptographique au moyen de la cle privee, puis 
destruction de la cle privee; et 

- mise en forme de la signature calculee a Taide du certificat de signature 
regu sur le canal authentifie. 

Un autre aspect de la presente invention se rapporte a un produit de 
programmation d'ordinateur, comprenant des instructions a executer dans un 
poste client disposant de ressources d'authentification aupres d'un serveur 
d'assistance a la signature electronique, lesdites instructions incluant: 

- des instructions pour generer un couple cle privee - cle publique apres 
etablissement d'un canal de communication authentifie entre le poste 
client et ledit serveur; 

- des instructions pour transmettre au serveur, sur le canal authentifie, une 
requete de certificat de signature generee au moyen d'au moins la cle 
publique; 

- des instructions pour recevoir du serveur, sur le canal authentifie, un 
certificat de signature obtenu en reponse a ladite requete; 

- des instructions pour calculer une signature cryptographique au moyen 
de la cle privee puis pour detruire la cle privee; et 

- des instructions pour mettre en forme la signature calculee a Taide du 
certificat de signature regu sur le canal authentifie. 

Ce produit de programmation peut etre telecharge d'un serveur 
d'assistance comme evoque ci-dessus. II peut aussi, en totalite ou en partie, 
etre un programme resident de la plate-forme constituant le poste client. 



1er depot 



- 12 - 

D'autres particularites et avantages de la presente invention 
apparaitront dans la description ci-apres d'exemples de realisation non 
limitatifs, en reference aux dessins annexes, dans lesquels : 

- la figure 1 est un diagramme illustrant un exemple de mise en oeuvre du 
procede selon Tinvention; 

- la figure 2 est un diagramme illustrant une variante du procede selon 
('invention. 

La figure 1 montre un poste client 1 disposant de ressources 
d'authentification, mais ne disposant pas de ressources (cles) de signature 
electronique. Le procede illustre par la figure lui permet neanmoins de signer 
electroniquement un document. Le poste client 1 entre pour cela en relation 
avec un serveur 2 d'assistance a la signature electronique. 

Le serveur 2 est apte a relayer des requetes de certificat (CSR, 
"Certificate Signing Request") qu'il regoit vers une autorite de certification (AC) 
qui les signe en faisant confiance au serveur. Le serveur peut en particulier 
etre confondu I'AC. Sinon, il peut se connecter avec authentication mutuelle a 
une AC, par exemple au moyen de la version 3 du protocole SSL ("Secure 
Sockets Layer" defini par la societe Netscape Communications Corporation). 
La communication entre I'AC et le serveur 2 peut eventuellement etre chiffree. 

Lors d'une phase prealable, Tutilisateur du poste client s'est enregistre 
aupres de TAC, qui verifie formellement son identite conformement a sa 
Politique de Certification, et dispose ainsi de toutes les donnees necessaires a 
la creation d f un certificat de signature. Cet enregistrement peut aussi etre 
effectue aupres d'une Autorite d'Enregistrement cooperant avec I'AC. 

A titre d'exemple non-limitatif, le poste client 1 peut utiliser, comme il 
est courant, un logiciel de navigation web capable d'executer des programmes 
ecrits dans un langage a code mobile tel que Java. De tels navigateurs sont 
par exemple "Internet Explorer" de la societe Microsoft Corporation, "Netscape 
Navigator" de la societe Netscape Communications Corporation etc. 

Ce poste client dispose par exemple d'un certificat d'authentification de 
type SSL. Le serveur 2 est dans ce cas equipe des fonctionnalites classiques 
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lui permettant lui permettant d'etablir une session SSLv3 securisee avec le 
poste client 1 apres avoir procede a son authentification. C'est dans cette 
session SSLv3 que seront echanges entre le poste client 1 et le serveur 2 tous 
les messages illustres sur la figure 1. 

5 La premiere etape du procede de la figure 1 consiste ainsi en 

I'authentification de I'utilisateur du poste client 1 aupres du serveur 2, et en la 
creation du canal authentifie, correspondant dans cet exemple a la session 
SSLv3 etablie. Dans le cas decrit ou les echanges client-serveur se font dans 
une session SSLv3, il est de preference effectue une authentification mutuelle 

10 du serveur et du poste client. On pourrait cependant se contenter d'authentifier 
simplement le client 1 , ou employer un protocoie autre que SSL. 

Ensuite, le serveur 2 telecharge sur ce canal authentifie un programme 
ecrit dans le langage a code mobile ("applet" dans le jargon de Java), 
comportant des instructions pour executer au poste client 1 les operations 
15 illustrees par la partie gauche de la figure. 

La premiere de.ces operations (etape 10) est la generation d'un couple 
cle privee (Kpr) - cle publique (Kpub) permettant la signature selon un procede 
de cryptographie asymetrique de type cdnnu, par exemple RSA ("Rivest, 
Shamir, Adelman"), DSA ("Digital Signature Algorithm"), EC-DSA ("Elliptic 
20 Curve DSA"), etc. 

Ensuite, I'applet fait generer au poste client 1 une requete de certificat 
de signature (etape 11). Cette requete est generee a partir d'au mois la cle 
publique Kpub obtenue a Tetape 10. Frequemment, elle sera generee a partir 
du couple Kpr - Kpub. La requete est transmise au serveur 2 dans la session 
25 SSLv3. 

La requete de certification (CSR) transmise par le client peut etre de 
tout format acceptable, standardise ou proprietaire. Parmi les formats 
standardises actuellement utilisables, on peut citer a titre non exhaustif: 
SPKAC, PKCS#10, CRS. La requete de certification peut contenir la preuve de 
30 possession de la clef publique ou non, des informations sur I'utilisateur ou non, 
et toute autre information susceptible d'y etre incluse et decrite dans la 
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Politique de Securite du service. 

Le serveur 2 se charge alors (etape 12) d'obtenir pour le poste client 1 
un certificat de signature de courte duree, qui permettra de certifier la cle 
publique Kpub. Le certificat est genere localement quand le serveur est 
5 confondu avec I'AC. Sinon, la requete CSR est relayee a I'AC et le serveur 2 
obtient le certificat de la part de celle-ci. 

Le certificat obtenu a I'etape 12 est avantageusement un certificat 
X.509 de courte duree (par exemple une journee, ou une heure), et comprend 
un key usage permettant de signer et dependant de I'application au sein de 
10 laqueile la signature doit etre effectuee. II est transmis au poste client 1 dans la 
session SSLv3. 

Le poste client 1 recoit ce certificat de signature a I'etape 13, et en 
extrait les parametres requis par l'applet pour la mise en forme des signatures 
electroniques. 

15 L'applet execute la signature cryptographique du document a I'etape 14 

au moyen de la cle privee Kpr generee a I'etape 10, puis elle commande la 
destruction de cette cle privee Kpr a I'etape 15. 

Une fois la signature effectuee et le certificat recupere, l'applet met en 
forme la signature electronique a I'etape 16, par exemple au format PKCS#7 
20 en incluant le certificat dans I'enveloppe PKCS#7. Le document signe peut 
alors etre stocke ou transmis a des tiers (non represents). Independamment 
de la signature cryptographique calculee a I'etape 14, la signature electronique 
(c'est-a-dire mise en forme) peut avoir n'importe quel format de signature: 
PKCS#7/CMS, XML-Dsig, PGP, etc. 

25 Dans la variante preferee illustree par la figure 2, le poste client 1 

execute en parallele les etapes 11 et 13 d'une part et les etapes 14 et 15 
d'autre part. 

L'invention n'est pas limitee aux modes de realisation qui ont ete 
decrits plus haut. 
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L'authentification de I'utilisateur du poste client 1 par le serveur 2 peut 
notamment etre effectuee par tout moyen d'authentification offrant le niveau de 
securite voulu, en conformite avec la Politique de Securite definie par I'AC pour 
le service de signature electronique. Parmi les modes d'authentification 
possibles, on peut citer: 

• le mot de passe statique, utilise dans le cadre d'un protocole proprietaire 
ou normalise, quelles que soient la taille du mot de passe ou les autres 
contraintes qui lui sont imposees; 

• le questionnaire, utilise dans le cadre d'un protocole proprietaire ou 
normalise, quels que soient le nombre de questions, la forme de ces 
questions, leur langue ou leur nature (mots, phrases, dessins, ...); 

• le mot de passe calcule, utilise dans le cadre d'un protocole proprietaire 
ou normalise, quels que soient la taille de ce mot de passe et son mode 
de calcul; 

• le mot de passe non reutilisable, utilise dans le cadre d'un protocole 
proprietaire ou normalise, quels que soient le support physique du mot de 
passe, sa forme, sa nature, sa taille; 

• le defi-reponse a clef secrete, utilise dans le cadre d'un protocole 
proprietaire ou normalise, quels que soient le support de la clef secrete, 
le mode et I'algorithme de calcul de la reponse, la nature, la forme, la 
taille du defi et de la reponse; 

• le defi-reponse a clef publique, utilise dans le cadre d'un protocole 
proprietaire ou normalise, quels que soient la nature, la taille et le support 
de la clef privee, le mode et I'algorithme de calcul de la reponse, la 
nature, la forme, la taille du defi et de la reponse, la nature du certificat 
et/ou de la clef publique. 

Le procede selon I'invention peut etre employe dans tout type 
d'environnement, par exemple: 

• dans le cadre d'un service web dans un navigateur, sous forme d'une 
applet comme decrit precedemment, mais aussi sous forme de script, 
d'appel a un composant de type "plug-in", a un programme exterieur, a 
un composant de type "ActiveX", a une librairie dynamique, etc.; 
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• dans le cadre d'un client de messagerie, par exemple sous forme d'appel 
a un composant de type "plug-in", a un programme exterieur, a une 
librairie dynamique, etc.; 

• dans le cadre d'une application independante, comme partie d'un service 
plus large tel que par exemple un service d'archivage securise, de 
publication securisee de documents, de gestion de flux de donnees 
("workflow", "dataflow"), etc.; 

• en tant que service autonome. 

Le client peut ne pas souhaiter authentifier le serveur. II lui suffit alors 
de verifier la validite du certificat detivre une fois qu'il I'aura recu. Dans le cas 
ou le client authentifie du serveur, il peut soit faire confiance a la validite du 
certificat puisqu'il a ete delivre par un serveur de confiance, soit verifier tout de 
meme la validite de ce certificat par les methodes traditionnelles de verification 
de chaTne de certificats de confiance. 

Le protocole employe entre le client 1 et le serveur d'authentification 2 
peut etre un protocole normalise ou un protocole proprietaire. Ce protocole 
peut etre securise ou non. Un exemple de protocole non securise utilisable est 
HTTP ("Hypertext Transfer Protocol", RFC 2616, juin 1999, IETF). Parmi les 
protocoles securises utilisables, on peut citer SSH de la societe SSH 
Communications Security, ou HTTPS (HTTP sur SSLv2 ou SSLv3). 

Un horodatage sur peut etre adjoint a la signature, avant ou apres la 
requete de certification. Cet horodatage peut etre fourni par le meme serveur 
que le reste du service ou par un serveur distinct. II peut notamment etre 
obtenu aupres d'un serveur d'horodatage, directement ou par I'intermediaire du 
serveur d'authentification. Cet horodatage peut etre a tout format 
techniquement correct et accepte dans le cadre de la Politique de Securite du 
service dans le cadre duquel le procede est employe. 

Dans le cas particulier decrit ci-dessus, c'est une applet qui se charge 
de generer les cles de signature (etape 10) puis d'effectuer la signature 
cryptographique et la mise en forme (etapes 14 et 16). Pour la fonction de 
generation de la cle a proprement parler, il y a egalement des alternatives: 
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• I'applet peut faire appel a une fonctionnalite deja presente dans le poste 
client pour generer la cle; 

• la generation de la cle peut avoir lieu avant le debut d'execution de 
I'applet, par le programme cadre (par exemple le navigateur ou I'outil de 
messagerie). 

D'autre part, Tapplet peut faire appel a une fonctionnalite deja presente 
sur le poste pour executer la signature cryptographique et/ou la mettre en 
forme. 
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REVENDIC ATIONS 

1. Procede de signature electronique depuis un poste client (1), 
comprenant les etapes suivantes: 

IN authentifier le poste client aupres d'un serveur (2), en etablissant ainsi 
5 un canal de communication authentifie entre le poste client et ledit 

serveur; 

IB/ generer un couple cle privee - cle publique au poste client; 

ICI transmettre du poste client au serveur, sur le canal authentifie, une 
requete de certificat de signature generee au moyen d'au moins la cle 
10 publique; 

ID/ transmettre du serveur au poste client, sur le canal authentifie, un 
certificat de signature obtenu en reponse a ladite requete; 

IE/ calculer une signature cryptographique au poste client au moyen de la 
cle privee, puis detruire la cle privee au poste client; et 

15 IF I mettre en forme la signature calculee a I'aide du certificat de signature 
regu par le poste client sur le canal authentifie. 

2. Procede selon la revendication 1, dans lequel les etapes ICI et IE/ 
sent executees en parallele au poste client (1). 

3. Procede selon Tune quelconque des revendications precedentes, 
20 dans lequel les etapes /B/, /C/, IE/ et IF/ sont au moins en partie executees au 

poste client (1 ) sous le controle d'un programme telecharge par le serveur (2) 
en reponse a Tetape IN. 

4. Procede selon Tune quelconque des revendications precedentes, 
dans lequel I'etape IN comprend une authentification mutuelle du serveur (2) et 

25 du poste client (1). 
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5. Procede selon Tune quelconque des revendications precedentes, 
comprenant une etape de verification par le poste client (1) du certificat de 
signature re?u sur le canal authentifie. 

6. Procede selon Tune quelconque des revendications precedentes, 
5 dans lequel le certificat de signature obtenu par le serveur (2) a une duree de 

validite d'au plus une journee. 

7. Procede selon Tune quelconque des revendications precedentes, 
comprenant une phase prealable d'enregistrement du poste client aupres d'une 
autorite de certification avec. laquelle coopere le serveur, ou d'une autorite 

10 d'enregistrement associee a cette autorite de certification. 

8. Produit de programmation d'ordinateur, comprenant des instructions 
a executer dans un poste client (1) disposant de ressources d'authentification 
aupres d'un serveur d'assistance a la signature electronique (2), lesdites 
instructions incluant: 

15 - des instructions pour generer un couple cle privee - cle publique apres 

etablissement d'un canal de communication authentifie entre le poste 
client et ledit serveur; 
.- des instructions pour transmettre au serveur, sur le canal authentifie, une 
requete de certificat de signature generee au moyen d'au moins la cle 

20 publique; 

- des instructions pour recevoir du serveur, sur le canal authentifie, un 
certificat de signature obtenu en reponse a ladite requete; 

- des instructions pour calculer une signature cryptographique au moyen 
de la cle privee puis pour detruire la cle privee; et 

25 - des instructions pour rnettre en forme la signature calculee a I'aide du 

certificat de signature re<?u sur le canal authentifie. 

9. Produit de programmation selon la revendication 8, dans lequel les 
instructions pour transmettre la requete de certificat de signature et les 
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instructions pour calcuier la signature electronique puis pour detruire la cle 
privee sont executables en parallele. 

10. Produit de programmation selon la revendication 8 ou 9, dans lequel 
certaines au moins desdites instructions font partie d'un programme ecrit en 
langage a code mobile, telechargeable depuis ledit serveur (2) apres 
etablissement du canal authentifie. 

11. Produit de programmation selon Tune quelconque des 
revendications 8 a 10, dans lequel lesdites instructions incluent en outre des 
instructions pour verifier le certificat de signature regu sur le canal authentifie. 

12. Serveur d'assistance a la signature electronique, comprenant des 
moyens d'authentification d'un poste client (1) pour etablir un canal de 
communication authentifie avec ledit poste client, des moyens pour obtenir un, 
certificat de signature en reponse a une requete regue du poste client sur le 
canal authentifie et pour transmettre ledit certificat au poste client sur le canal 
authentifie, et des moyens pour telecharger vers le poste client un programme 
ecrit en langage a code mobile et incluant des instructions pour controler au 
moins en partie Pexecution des operations suivantes par le poste client: 

- generation d'un couple cle privee - cle publique au poste client apres 
etablissement du canal authentifie; 

- transmission au serveur, sur le canal authentifie, d'une requete de 
certificat de signature generee au moyen d'au moins la cle publique; 

- reception, sur le canal authentifie, du certificat de signature transmis par 
le serveur en reponse a ladite requete; 

- calcul d'une signature cryptographique au moyen de la cle privee, puis 
destruction de la cle privee; et 

- mise en forme de la signature calculee a I'aide du certificat de signature 
re?u sur le canal authentifie. 

13. Serveur d'assistance selon la revendication 12, dans lequel le 
certificat de signature a une duree de validite d'au plus une journee. 
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14. Serveur d'assistance selon la revendication 12 ou 13, dans lequel 

lesdites operations comprennent en outre une verification du certificat de 
signature regu sur le canal authentifie. 



1er depot 



1/2 




CLIENT 



AUTHENTIFICATION 



TELECHARGEMENT APPLET 



GENERATION 
Kpr/Kpub 



I 



GENERATION 
REQUETE DE 
CERTIFICAT (Kpr.Kpub) 



TRANSMISSION REQUETE 



ENVOI CERTIFICAT DE SIGNATURE 



RECEPTION ET 
VERIFICATION 
CERTIFICAT 



I 



SIGNATURE (Kpr) 

I 



DESTRUCTION DE Kpr 

i 



MISE EN FORME 
SIGNATURE 



FIG. 1 



SERVEUR 



OBTENTION 
CERTIFICAT 



12 



1 er depot 



2/2 




IN 5 ! 



■ INITITUT 
NATIONAL t>t 
LA PROPBKTR 
lNDUDTRIH.lt 



re?ue le 07/1 0/02 

BREVET D'INVENTION 
CERT1FICAT D'UTILITE 

Code de la propri6te intellectuelle - Livre VI 



N° 11235'02 



DEPART EM ENT DES BREVETS 

26 bis, rue de Saint Petersbourg 
75800 Paris Cedex 08 



DESIGNATION D'INVENTEUR(S) Page N° }../}.. 
(Si le demandeur n'est pas Tinventeur ou Tunique inventeur) 



Vos references pour ce dossier 

(faailtatif) 


BLO/MGO-BFF020292 


N° D'ENREGISTREMENT NATIONAL 





TITRE DE L'INVENTION (200 caracteres ou espaces maximum) 

PROCEDE DE SIGNATURE ELECTRONIQUE, PROGRAMME ET SERVEUR POUR LA MISE EN OEUVRE DU 
PROCEDE. 



LE(S) DEMANDEUR(S) : 

FRANCE TELECOM 



DESKGNE(NT) EN TANT QU'INVENTEUR(S) : (Indiquez en haut a droite «Page N° S'il y a plus de trois inventeurs, 
utiiisez un formulaire identique et numerotez chaque page en indiquant le nombre total de pages), 



Nom 


ARDITTI 


Prenoms 


David 


Adresse 


Rue 


46ter, rue Paul Vaillant-Couturier 


Code postal et ville 


92140 | CLAMART 


Societe d'apparter 


lance (faailtatif) 




Nom 


FRISCH 


Prenoms 


Laurent 


Adresse 


Rue 


27, avenue d'ltalie 


Code postal et ville 


75013 PARIS 


Societe d'apparte 


nance (faailtatif) 




Nom 


MOUTON 


Prenoms 


Dimitri 


Adresse 


Rue 


11 , rue Antoine Bourdelle 


Code postal et ville 


75015 PARIS 


Societe d'appartenance (faailtatif) 




DATE ET SIGNATURE(S) 
DU (DES) DEMANDEUR(S) 
OU DU NJANDATAIRE 
(Nom et qualite du signataire) 

Le 1 8 septembre 2002, 
Bertrand LOIS EL 
CPIn° 94-31 1 


CD ^ 


^ — 



La loi n°78-17 du 6 janvier 1978 relative a Tinformatique, aux fichiers et aux libertes s'applique aux reponses faites a ce formulaire. 
Elle garantit un droit d'acces et de rectification pour les donnees vous concernant aupres de I'INPt. 



• 

f • 



